home *** CD-ROM | disk | FTP | other *** search
/ WINMX Assorted Textfiles / Ebooks.tar / Text - Tech - OS - NT - security guide 11.txt < prev    next >
Text File  |  2003-09-27  |  5KB  |  85 lines
  1. NT security guideSection 11
  2. Mathematical/Theoretical
  3.  
  4. 11-1. Can sessions be hijacked?
  5. 11-2. Are "man in the middle" attacks possible?
  6. 11-3. What about TCP Sequence Number Prediction?
  7.  
  8.  
  9.  
  10. 11-1. Can sessions be hijacked?
  11. In theory, however no one has yet coded the exploit. It would involve a complex 
  12. spoofing job where not only would the session have to be hijacked at the 
  13. transport level (getting all of the ACK/NACK numbering correct), but the tree ID 
  14. (TID) and user ID (UID) would have to be spoofed at the redirector and server 
  15. level respectively. We are talking SMB at this point. 
  16. A more likely session to be hijacked would be a telnet session to an NT server, 
  17. but this applies to any straight telnet session, NT or not, and is beyond the 
  18. scope of this FAQ. For more information refer to 
  19. http://www.nmrc.org/files/unix/ip-exploit.txt.. 
  20.  
  21.  
  22.  
  23. 11-2. Are "man in the middle" attacks possible?
  24. Ealry versions of LANMAN send the password in the clear -- which is definately 
  25. sniffer-bait. But the challenge/response authentication used by LANMAN 2.1 and 
  26. earlier is subject to possible attack -- namely a plaintext attack. Since the 
  27. challenge is plaintext, an attacker can acquire known plaintext/ciphertext 
  28. pairs. Offline, the attacker can then test a guess at a password by using it to 
  29. generate a key, encrypting the plaintext, and comparing it to the corresponding 
  30. ciphertext. If it matches, the password is compromised. 
  31. Since case doesn't matter, a brute force attack is theoretically possible 
  32. against plaintext/ciphertext pair obtained via a known plaintext attack. 
  33. However, this is simply offline attacking. A true man-in-the-middle attack 
  34. allows a third party to intercept and replace components of the 
  35. challenge/response conversation with their own, acquiring the password or even 
  36. taking over the session itself. However, the easier of the two is getting the 
  37. password. 
  38. By catching the start of a conversation and forging the challenge, the client 
  39. would response with the response to the server, and the attacker would know a 
  40. part of the equation, shortening the time and effort needed to break the 
  41. plaintext/ciphertext pair. 
  42. By "precompiling" a list of response/password pairs, the password could be 
  43. determined even quicker. 
  44. NT LM 0.12 uses MD4 to generate keying material, and since upper and lower case 
  45. are allowed, the full 56 bits allowed by DES can be used. This does not 
  46. eliminate the problem -- it simply increases the difficulty of brute force 
  47. against a plaintext/ciphertext pair. 
  48. However this does nothing towards a realtime attack. The best method would be as 
  49. follows: 
  50.   Client starts a session. 
  51.   Attacker sees this session, and waits for the response from the server. 
  52.   Server sends the response and the Attacker grabs it. 
  53.   Attacker removes the SMB_COM_NEGPROT bit and sends it to the Client. 
  54.   Client receives the Attacker's packet, and now assumes a plaintext password 
  55.   should be used. 
  56.   Client receives the real packet from the server, but ignores it thinking it is 
  57.   a dupe. 
  58.   Client sends the password in plaintext. 
  59.   Attacker grabs the password and now logs into the Server directly. 
  60.   Client times out or gets an error, and figures a network error has occurred. 
  61.   Client tries to log in again. 
  62. It is also possible in theory to catch the session before the authentication 
  63. process even starts. For example: 
  64.   Client starts a session, and sends a request to the DNS server to resolve a 
  65.   host name. 
  66.   Attacker sees this request, and forges a reply that the Attacker's IP address 
  67.   is the address for the host the Client is requesting. 
  68.   Attacker sends request to DNS server cancelling Client's request. 
  69.   Client starts to log into Attacker. 
  70.   Attacker tells Client to send the password as plaintext. 
  71.   Client complies, and Attacker proceeds to login to original host that the 
  72.   Client was asking the DNS server about. 
  73.   Attacker kills the session with the Client, and the Client thinks an error has 
  74.   occurred, and tries again. 
  75. This attack has been partially implemented with the c2myazz file, which forces a 
  76. plaintext login. 
  77.  
  78.  
  79.  
  80. 11-3. What about TCP Sequence Number Prediction?
  81. Refer to section 10-1. This is possible, but unlikely, on anything requiring the 
  82. TID and UID as a part of the spoof. TCP Sequence Number Prediction involves 
  83. guessing what the TCP numbering sequence is, and inserting packets to 
  84. (typically) execute commands on the target host with the proper sequence number. 
  85.